Web2.0時代の必要技術　～　SOA 再入門

第二部：BPELの可能性―ワークフローのスクリプト化は可能か

第一部で述べたように、SOAにはビジネス・プロセスのワークフローを定義するBPELという言語と、その定義に従ってWebサービスを順次呼び出していくBPELエンジンというツールがある。この仕組みは実用に耐えるなら、システム開発作業にとって新たなコンセプトと強力なツールとなる。本稿では、BPELの機能の概略を調べ、BPELの可能性を検討する。

XMLを使ってスクリプトを記述する試みは、これまでもなされてきた。しかし、BPELは(1)ワークフロー定義に特化したこと、(2)Webサービスの呼び出し専用の機能であることなど、特異なものである。
BPELは標準化団体のOASISで作業が行われている規格である。BPEL4WS（Business Process Execution Language for Web Services）という規格が、現在はWS-BPEL（Web Services Business Process Execution Language）という名称で標準化作業が行われている。なお、本稿では、簡略してBPELと表記する。

BPELの基本機能

BPELはワークフローを記述する言語であり、BPELエンジンは、ワークフローのスクリプトともいえるそのBPEL文書を読み込んで、Webサービスを呼び出しながら処理を進める仕組みを提供する。BPELには、使用するWebサービスについての記述を行う部分と、実際のビジネス・プロセスのフローを記述する部分がある。（図10）

Webサービスの記述は、WSDLに基づく。この部分では、WSDLのメッセージの種類（message）、サービスの種類を示すポート型（portType）、またサービスのやり取りにおける関係の種類を示すパートナーリンク型（partnerLinkType）を定義する。いわゆる「型定義」である。

ビジネス・プロセスの定義は<process>で始める。BPELでは、サービスの提供元を「パートナー（partner）」と考える。まず、パートナーとの関係と役割を<partnerLink>で、参照するパートナーの情報を<partners>で記述する。また、実行時の変数の宣言<variables>や、各トランザクションを識別するための情報である相関セット<correlationSets>も定義できる。さらに、エラー処理<faultHandlers>や補正処理<compensationHandlers>なども記述できる。これらを定義した後、具体的なビジネス・プロセスのフローを記述する。定義するビジネス・プロセスの単位をアクティビティ（Activity）といい、アクティビティの順序を定義したものがワークフローとなる。
アクティビティのフローを次の要素で制御する。（フローチャートとの対応は、図11）

1. ◆ 順次<sequence>
2. ◆ 繰り返し<while>
3. ◆ 選択<switch>、<case>、<otherwise>
   そして、アクティビティとして記述できるのは、Webサービスに関連した、次の基本的な活動である。
4. ◆ Webサービスの呼び出し　<invoke>
5. ◆ メッセージの受信<receive>
6. ◆ メッセージの送信<reply>
7. ◆ 強制終了<terminate>
8. ◆ 待機<wait>
9. ◆ 変数へ割り当て<assign>
10. ◆ 空のアクティビティ<empty>
11. ◆ 障害の通知<throw>

<process>
 ……
  <sequence>
    <invoke operation=”A”  />
    <invoke operation=”B”  />
  </sequence>
</process>

　これら以外にも、並列処理を行うための<flow>、補正処理を行う<compensate>、メッセージを保管する<container>、イベント処理に関連した<pick>、<onMessage>、<onAlarm>、スコープ（有効範囲）を指定する<scope>などがある。
本稿では、各機能の詳細に立ち入らないが、ビジネス・プロセスの基本的な処理の流れを定義するのにじゅうぶんな機能が備わっていることが大体わかるだろう。

BPELの特徴－補正機能とスコープ

BPELの特徴のひとつは、補正（compensate）機能（または補償機能）とスコープ（有効範囲）という考え方にある。
補正とは、ある範囲で行った処理をさかのぼって取り消していく処理のことである。たとえば、物品の注文処理をして、注文された品はA、B、Cという商品を組み合わせた構成品だったとしよう。この場合、A、B、Cという三つの商品の在庫を確認できて初めて受注可能である。もしAとBは在庫があって予約をしたが、Cは在庫がなかった場合、どのような処理が必要だろうか。それはBからAへさかのぼり、在庫予約を取り消す処理である。このような取消処理を補正という。

BPELでは、あらかじめ通常処理（例、商品予約）と補正処理（例、商品予約取消）の処理の両方を定義しておき、補正処理が必要となった場合に、BPELエンジンがさかのぼって補正を実行する。

では、どこまでさかのぼればよいのだろうか。答えは、スコープ（有効範囲）の範囲までである。このように予め有効範囲を定義しておくことにより、補正処理の範囲を指定できるのである。

BPELの可能性

BPELおよびSOAの考え方は、一般的なシステム開発の手順と、考え方や発想の点で異なっている。サービス中心の考え方をするなら、サービスの分析と粒度の検討という新たな視点での作業が必要となる。いわば「サービス・アナリスト」の仕事である。

また、BPELにおけるビジネス・プロセスのスクリプト化は、柔軟性のあるシステム構築を可能にする。提供されるサービスが先見性のある堅牢なものであるなら、エンドユーザーによる開発や保守も可能になるかもしれない。もちろん、BPELもしくはその発展形がシステム開発の生産性を向上させるには、BPEL開発支援ツールの充実、BPELエンジンの無償化、部品としての多様なサービスの流通（ネット経由での）が不可欠である。（フリーのBPEL開発支援ツールとしては、ActiveBPEL Designer（http://www.active-endpoints.com/）がある。）
もっともBPELエンジン自体がまだ高価である。しかし、XMLの前身であるSGMLの時代、SGMLパーサーは高価だったが、SGMLがXMLに発展して広く使われるようになると、Microsoftや他のベンダーはXMLパーサーを無償で提供するようになった。同様に、BPELが広く普及し、BPELエンジンの無償化へ進むことを期待している。

しかし、何よりも必要なのはWebサービスが部品として広く流通することである。信頼性の高い部品としてのWebサービスが豊富に存在するようになれば、それを利用するための技術も発展し、普及していくだろう。こうした諸条件が満たされ、BPELがビジネス・プロセスのワークフローのスクリプト化、およびシステム開発の新たなパラダイムへの転換が進むことを期待している。

【参考文献】
・米持幸寿著、『基礎から分かるSOA』、日経BP社、2005年
・トーマス・フリードマン著、『フラット化する世界－経済の大転換と人間の未来(上)（下）』、伏見威蕃訳、日本経済新聞社、2006年
・日本ユニテック Digital Xpress編集部著、『SOAP/UDDI/WSDL Webサービス技術 基礎と実践徹底解説』、
技術評論社、2002年
・Web Services Business Process Execution Language Version 2.0, Committee Draft, 17th May, 2006
・BPEL4WS文書を作成するためのリファレンス・ガイド
　（IBM developerWorksのWeb servicesにある記事）